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Response to Amendment 

Applicant's arguments filed on August 03, 2007 have been 
considered but are not deemed persuasive. 

Claims 1-26 are presented for examination. 

Response to Arguments 

In essence the Applicant argues "At a minimum, Adelman fails to 
teach sending a response to a keepalive message where the 
response to the keepalive message includes an indication of a 
load-based keepalive period." (Page 11, 4 th paragraph and pa'ge 
12, second paragraph). Examiner respectfully disagrees. Adelman 
teaches calculating adaptive keepalive period based on packet 
loss (load indication) (col. 8, lines 20-23). 

Adelman also teaches "Each client includes a sequence number in 
its "client keepalive" packet. When the master gets this 
keepalive packet for client "x" he makes the following 
calculations : 

(1) S . sub .. DELTA. =[this sequence number ]-[ last sequence 
number] -1... The resulting value of "n" is the adaptive 
keepalive interval which the master then sends to all of the 
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cluster members to use in determining how often they are to send 
their "Client keepalive" message . " (Col . 13, lines 42 to col. 14, 
lines 13). Therefore, Adelman teaches the argued limitations. 

Claim Rejections - 35 USC § 102 

The following is a quotation of the appropriate paragraphs 
of 35 U.S.C. 102 that form the basis for the rejections under 
this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in' a printed publication in this or 
a foreign country or in public use or on sale in this country, more than one 
year prior to the date of application for patent in the United States. 

Claims 1,3,4, 7-10, 13, 14-15, 19,25, and 26 are rejected 
under 35 U.S.C. 102(b) as being anticipated by Adelman et al . 
(US 6078957), hereinafter "Adelman". 

As per claim 1, Adelman teaches a method comprising: 

receiving a keepalive message from a client (col. 8, lines 

14-16 and col. 9, lines 3-5); 

determining a measure of network load (packet loss is a 

measure of network load that is determined by the master, "... 

master calculates and stores a packet loss average value using 
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the sequence number of the client keepalive message and the 
calculated adaptive keepalive interval." column. 8, lines 20- 
23.) ; 

based on the measure of network load, selecting a keepalive 
period (based on packet loss, an adaptive keep alive period is 
calculated, " ... the master calculates and stores a packet loss 
average value using the sequence number of the client keepalive 
message and the calculated adaptive [i.e. changes the ] 
keepalive interval", column 8, lines 20-23); 

reporting the selected keepalive period to the client 
station in a response to the received keepalive message (col. 
13, lines 42 to col. 14, lines 13) (selected keep alive period 
is reported to client, "As indicated above, the master 
periodically [presence server] sends out a master keepalive 
message containing the cluster member list, the adaptive 
keepalive interval ..." column 8, lines 31-33); and the 
client station responsively sending a keepalive message to a 
presence server at a time determined based on the selected 
keepalive period (client sends keep alive messages with updated 
adaptive keepalive interval, "The non-master cluster members 
(clients) must also send keepalive message and ..." Column 9, 
lines 2-3 in conjunction with, "... when a client gets a master 
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keepalive message 890 it updates its adaptive keepalive interval 
891 . ..", Column 9, lines 4-6). 

For Claim 3: The method of claim 1 (see supra for claim 1 
discussion) , wherein determining a measure of network load 
comprises: the presence server (cluster master, which is also 
cluster member, "... each of the cluster members is a computer 
system...", column 5, line 22; acting as master) querying a* 
controller (has controller, "... and two Intel Ethernet 
controllers," column 5, line 24) that has access to network load 
information (FIG. 1 in conjunction with FIG. 4, FIG. 1 Item 110 
is the cluster one ether net connected to other network units. 
To get the sequence number master must have queried and obtained 
the packet from the Ethernet controller.). 

For Claim 4: A presence server (master of the cluster) in a* 
communication network (see FIG. 1, item 110, in conjunction with 
column 5, line 16-17, "...will be described as a cluster whose 
applications may be VPN tunnel...", which indicates that FIG. 1, 
Item 110 is a cluster), comprising: 

a first module (see FIG. 8B, item .830, a module) arranged 
to receive keepalive messages from at least one client station 
(master got client keepalive) ; a second module (a second module, 



Application/Control Number: 1 0/667,88 1 Page 6 

Art Unit: 2153 

see FIG . 8B, item 835) arranged to select a keepalive period 
based on a measure of network load (FIG. 8B, Item 835, 
"CALCULATE AND STORE PACKET LOSS AVERAGE (USING SEQUENCE NUMBER 
OF KEEP ALIVE AND ADAPTIVE KEEPALIVE INTERVAL)", Packet average 
loss is the measure of network load, and adaptive keepalive' 
interval is keepalive period based on network load) ; a third 
module (FIG. 8C, item 851) arranged to report the selected 
keepalive period to the at least one client station (FIG. 8C, 
item 851, "BROADCAST MASTER KEEPALIVE CONTAINING CLUSTER MEMBER 
LIST AND ADAPTIVE KEEPALIVE INTERVAL"). 

For claim 7: The presence server of claim 4 (see supra for claim 
4 discussion) , wherein the presence server is coupled to a 
controller (a master which is also cluster member has two 
Ethernet controllers, "each of the cluster members is a computer 
system having an Intel motherboard, two Intel Pentium 
processors, a 64 megabyte memory and two Intel Ethernet 
controllers, ... ") , the controller keeping track of network load 
information (the controller receives the packets, therefore 
controller keeps track of packet sequence numbers, which in turn 
determine network packet loss-network load, "... when the master 
gets a 'client, keepalive message 1 (that is one from a non-master 
cluster member) 830 . . . master calculates and stores a packet 
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loss average value using sequence number of the client keepalive 
message and the calculated adaptive keepalive interval. Column 
8, lines 15-23) . 

For claim 8: The presence server of claim 4 (see supra for claim 
4. discussion) , wherein the presence server is embedded with a 
controller (a master which is also cluster member has two 
Ethernet controllers that are present on the mother board or 
attached to mother board, i.e. they are embedded, "each of the 
cluster members is a computer system having an Intel 
motherboard, two Intel Pentium processors, a 64 megabyte memory 
and two Intel Ethernet controllers.... ") that keeps track of 
network load information (the controller receives the packets 
with packet sequence number, therefore controller keeps track of 
packet sequence numbers, which in turn determine network packet 
loss, which is a measure of network load, "... when the master 
gets a 'client keepalive message 1 (that is one from a non-master 
cluster member) 830 . . . master calculates and stores a packet 
loss average value using sequence number of the client keepalive 
message and the calculated adaptive keepailive interval.", column 
8, lines 15-23) . 
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For claim 9: Adelman teaches a system comprising: 

at least one client station (FIG. 4, Items 405-409 as non- 
master cluster members) ; a presence server (Master acting as 
presence server and for description of master formation please 
refer to FIG. 6 - 8A, in conjunction with reference to column 6, 
line 40 - column 8, line 13); the presence server receiving a 
keepalive message from the at least one client station (col. 8, 
lines 14-16 and col. 9, lines 3-5); 

the presence server determining a keepalive period 
(keepalive period is determined by master based on packet loss, 
which is a measure of network load, "... when the master gets a 
1 client keepalive message 1 (that is one from a non- master 
cluster member) 830 . . . master calculates and stores a packet 
loss average value using sequence number -of the client keepalive 
message and the calculated adaptive keepalive interval.", column 
8, lines 15-23) based on network load (packet loss rate is a 
measure of network load) and sending an indication of the 
keepalive period to the at least one client station in a 
response to the keepalive message (col. 13, lines 42 to col. 14, 
lines 13) (FIG. 8C, item 851, "BROADCAST MASTER KEEPALIVE 
CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE KEEPALIVE 
INTERVAL") ; 

the at least one client station sending keepalive signals 
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according the keepalive period (See FIG. 8H, Item 912, "SEND 
CLIENT KEEP ALIVE TO MASTER CONTAINING MONOTONICALLY INCREASING 
SEQUENCE # (FOR MEASURING NETWORK PACKET LOSS" in conjunction 
with column 9, lines 13-17, "Each client also has a periodic 
timer which is adaptive to the network packet loss value send by 
the master which requires the client to send a client keepalive 
message (containing a monotonically increasing numeric value) to 
the master periodically"). 

For claim 10: The system of claim 9 (see supra for claim 9 
discussion) , further comprising a controller that has access to 
network load information (FIG. 1 in conjunction with FIG. 4, 
FIG. 1 Item 110 is the cluster one ether net connected to other 
network units. To get the sequence number master must have 
queried and obtained the packet from the Ethernet controller.). 

For claim 13: The communication network of claim 9 is a packet- 
switched network (see FIG. 1, Item 110 the cluster connecting to 
internet 107 through communication link 109, It is well known 
that internet is a packet-switched network) . 

For claim 14: A method comprising: sending a first keepalive 
message from a client station to a presence server (FIG. 8B, 
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Item 830, "MASTER [master is presence server] GOT CLIENT 
KEEPALIVE") ; selecting a keepalive period based on a measure of 
network load (FIG. 8B, item 835, "CALCULATE AND STORE PACKET 
LOSS AVERAGE (USING SEQUENCE NUMBER OF KEEPALIVE AND ADAPTIVE 
KEEPALIVE INTERVAL", the packet loss average is network load and 
keepalive period is changed based on this load)"; reporting the 
selected keepalive period to the client station" (FIG. 8C, 
"BRAODCAST MASTER KEEPALIVE CONTAINIGN CLUSTER MEMBER LIST AND 
ADAPTIVE KEEPALIVE INTERVAL"); using the selected keepalive 
period to determine when the client station should send a next 
keepalive message to the presence server (See FIG. 8H, Item 912,- 
"SEND CLIENT KEEP ALIVE TO MASTER CONTAINING MONOTONICALLY 
INCREASING SEQUENCE # (FOR MEASURING NETWORK PACKET LOSS" in 
conjunction with column 9, lines 13-17, "Each client also has a 
periodic timer which is adaptive to the network packet loss 
value sent by the master ..."); sending the next keepalive 
message from the client station to the presence server (client, 
i.e. non-master sends the keep alive message to master, i.e. 
presence server, " .... which requires the client to send a client 
keepalive message (containing a monotonically increasing numeric 
value) to the master periodically (see FIG. 8H) [item 912].", 
column 9, lines 14-17). 
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For claim 15: The method of claim 14 (see supra for claim 14 
discussion) , wherein selecting the keepalive period based on the 
measure of network load comprises: 

the presence server selecting the keepalive period based 
on the measure of network load (FIG. 8B, item 835, "CALCULATE 
AND STORE PACKET LOSS AVERAE [packet loss average is network 
load] (USING SEQUENCE NUMBER OF KEEPALIVE AND ADAPTIVE KEEPALIVE 
INTERVAL) 

For claim 19: Adelman teaches a client station (Cluster member 
as described in column 5, lines 22) in a communication network 
(see FIG. 1 Item 107), the client station comprising: a receiver 
(column 5, line 24, "... two Ethernet controllers", which 
implies a ether net phy with a receiver) ; a transmitter (column 
5, line 24, "... two Ethernet controllers", which implies a 
ether net phy with a transmitter) ; a timer (column 9, lines 13- 
16, "Each client also has a periodic timer which is adaptive to 
the network packet loss value sent by the master which requires 
the client to send a client keepalive message ..."); at least 
one processor (column 5, line 22, "... two Intel Pentium 
processors"); data storage holding program instructions (FIG. 2, 
Item 217, CD-ROM medium in conjunction with column 4, line 42, 
"... a CD-ROM drive unit 217. The CD-ROM drive unit 217 can read 
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a CD-ROM medium 219 which typically contains program 221 ...",); 
the program instructions being executable by the at least one 
processor to send a keepalive message through the transmitter, 
and to receive through the receiver a response to the keepalive 
message, the response containing information defining a 
keepalive period, the keepalive period being selected based, on 
network load (column 9, lines 13-16 and col. 13, lines 42 to 
col. 14, lines 13); and 

the program instructions being executable by the at least 
one processor, in response to receiving information defining a 
keepalive period wherein the keepalive period is selected based 
on network load (column 9, lines 13-16, "Each client also has a 
periodic timer which is adaptive to the network packet loss 
value [network packet loss value is a measure of network load) 
sent by the master which requires the client to send a client 
keepalive message ..."), to: (i)-set the timer according to the 
keepalive period (column 9, lines 13-16, "Each client also has a 
periodic timer which is adaptive to the network packet loss 
value [network packet loss value is a measure of network load) 
sent by the master which requires the client to send a client 
keepalive message ..."); (ii) send a new keepalive message 
through the transmitter when the timer expires (column 9, lines 
13-16, "Each client also has a periodic timer which is adaptive 
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to the network packet loss value [network packet loss value is a 
measure of network load) sent by the master which requires the 
client to send a client keepalive message ..."). 

For claim 25: A presence server in a communication network 
comprising: a database, the database maintaining a list client 
stations that are connected to the network (column 8, lines 31- 
33, "As indicated above the master periodically sends out a 
master keepalive message containing the cluster member list 
. ..", since cluster member list is being sent, they must be 
stored in a database) ; a timer (column 9, lines 13-16, "Each 
client also has a periodic timer which is adaptive to the 
network packet loss value sent by the master which requires the 
client to send a client keepalive message ...")•; wherein the 
presence server (master is the presence server) is programmed 
to: receive keep alive messages from at least one client station 
(See FIG. 8B, item 830, "MASTER GOT CLIENT KEEPALIVE"), select 
a keepalive period for the at least one client station based on 
a measure of network load (FIG. 8B, Item 835, "CALCULATE AND 
STORE PACKET LOSS AVERAGE (USING SEQUENCE NUMBER OF KEEPALIVE 
AND ADAPTIVE KEEPALIVE INTERVAL", where packet loss average is 
measure of network load based on which keepalive interval is 
determined.), report the selected keepalive period to the at 
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least one client station in a response to the received keepalive 
message (col. 13, lines 42 to col. 14, lines 13) (FIG. 8C, item 
851, "BORADCAST MASTER KEEPALIVE CONTAINING CLUSTER MEMBER LIST 
AND ADAPTIVE KEEPALIVE INTERVAL"), and drop the at least one 
client station from the database (FIG. 8E, ITEM 871, "DELETE 
CLIENT FROM CLUSTER DATA STRUCTURE") if the presence server does 
not receive new keepalive message within the selected keepalive 
period from the at least one client station (FIG. 8E, ITEMS 870, 
WATCHDOG TIMER FOR A CLIENT EXPIRES", which means presence 
server did not receive a keepalive message from the client.). 

For claim 26: A method comprising: sending a first keepalive 
message from a client station to a presence server (See FIG. 8B, 
item 830, "MASTER GOT CLIENT KEEPALIVE", which means client must 
have sent a keepalive message) ; selecting a keepalive period 
based on a measure of network load (FIG. 8B, Item 835, 
"CALCULATE AND STORE PACKET LOSS AVERAGE (USING SEQUENCE NUMBER 
OF KEEPALIVE AND ADAPTIVE KEEPALIVE INTERVAL", where packet loss 
average is measure of network load based on which keepalive 
interval is determined.); reporting the selected keepalive 
period to the client station in a response to the first 
keepalive message (col. 13, lines 42 to col. 14, lines 13) 
(FIG. 8C, item 851, "BORADCAST MASTER KEEPALIVE CONTAINING 
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CLUSTER MEMBER LIST AND ADAPTIVE KEEPALIVE INTERVAL"); using the 
selected keepalive period to determine when the client station 
should send a next keepalive message to the presence server 
(FIG. 8B, item 837, ".RESET WATCHDOG FOR THIS CLIENT", when this 
timer expires, i.e. with in adaptive keepalive interval if • 
client does not send a keepalive message, client will be 
removed) ; updating a database of the presence server based on 
whether the client station has sent a next keep keepalive 
message to the presence within the selected keepalive period 
(FIG. 8E, item 870, WATCHDOG TIMER FOR CLINET EXPIRES", if 
keepalive message is received by master it watchdog timer would 
have been reset, See FIG. 8B, item 837 in conjunction with item 
830) .. 



Claim Rejections - 35 USC §103 



The following is a quotation of 35 U.S.C. 103(a) which, 
forms the basis for all obviousness rejections set forth in this 
Office action: 

(a) A patent may not be obtained though the invention is not identically 
disclosed or described as set forth in section 102 of this title, if the 
differences between the subject matter sought to be patented and the prior 
art are such that the subject matter as a whole would have been obvious ' at 
the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 
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5. Claims 2, 6, 12, 17, 20, 22 and 24 are rejected under 35 ' 
U.S.C. 103(a) as being unpatentable over Adelman et al. in view 
of Harsch (US 6212175 Bl) . 

For claims 2, 6, and 12 Adelman et al. teaches everything except 
client being wireless mobile workstation, or presence server 
present in wireless communication network. The general concept 
of client being wireless workstation or presence server being 
present in wireless communication network is well known in the 
art as shown in Figure 1 use of MOBILE UNIT as client or 
presence server being present in a wireless network (Harsch: see 
the Figure 1, items 66, 66a, 66b, etc., which are mobile units 
which are present in a wireless communication network (see item 
67 indicating being wireless antenna) and presence server being 
Item 60, Host computer) . It would have been obvious to one in 
skilled in the art at the time of the invention to modify 
Adelman et al. to have a wireless mobile workstation and 
presence server in a wireless communication network in order to 
sustain TCP connection as taught in Harsch (see title, "METHOD 
TO SUSTAIN TCP CONNECTION"). 
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For claim 17, Adelman et al teaches all the limitations of claim 
17 except serving one or more wireless mobile ■ subscribers in a 
wireless communication system. The general concept of serving 
one or more wireless mobile subscribers in a wireless 
communication system is well known in the art as illustrated by 
Harsch (FIG. 1, items 66, 66a, and 66b, several mobile units 
serving various subscribers in a wireless communication system) . 
It would have been obvious to one in skilled in the art at the 
time of the invention to modify Adelman et al to serving one or 
more wireless mobile subscribers in a wireless communication 
system in order to serve various mobile stations in a wireless 
communication system as taught in Harsch (see FIG. 1, serving 
various mobile units items 66, 66a, and 66b in a wireless 
communication network as shown in FIG. 1) . 

For claim 20: A system for dynamically determining keepalive 
periods in a wireless communication network, comprising: at 
least one base station (this claim limitation is not taught) ; at 
least one client station (FIG. 4, Items 405-409 as non-master 
cluster members); a presence server (FIG. 4, Item 403 as master, 
acting' as presence server); A packet switched network (see FIG. 
4, Items 411 and 107, INTERNET is known to be packet switched 
network) ; The presence server (master, which will be one of 
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items 403-409) being capable of communicating with at least one 
client station (All items 403-409 which is not master are 
clients) through the packet-switched network (FIG, 8B, item 830, 
"MASTER GOT CLIENT KEEPALIVE", since keepalive is a packet, it 
is implicit that there must be packet-switched network) ; the 
presence server determining a keepalive period (keepalive period 
is determined by master based on packet loss, which is a measure 
of network load, "... when the master gets a 'client keepalive 
message 1 (that is one from a non- master cluster member) 830 ... 
master calculates and stores a packet loss average value using 
sequence number of the client keepalive message and the 
calculated adaptive keepalive interval.", column 8, lines 15-23) 
at least one mobile subscriber (this claim limitation is not 
taught by Adelman et al) based on network load (packet loss rate 
is a measure of network load) and the presence server reporting 
the selected keepalive period (FIG. 8C, item 851, "BROADCAST 
MASTER KEEPALIVE CONTAINING CLUSTER MEMBER LIST AND ADAPTIVE 
KEEPALIVE INTERVAL") to the at least one mobile subscriber (this 
limitation is not taught by Adelman et al) through the packet- 
switched network (see FIG. 4, Items 411 and 107, INTERNET is 
known to be packet switched network) ; Adelman et al teaches all 
the claim limitations as discussed above except for coupling a 
mobile client (s) through a base station to a packet switched 
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network server. The general concept of coupling mobile user 
through a base station to a packet switched network server is 
well known in the art as illustrated by Harsch (see FIG. 1, 
items 66, 66a, and 66b mobile stations, coupled to server (host 
computer) through bases station 54a, wired line 52 (see page 4, 
Para 0037, lines 4-6, "The network backbone 52 may be a 
hardwired data communication path made of twisted pair cable, 
shielded coaxial cable or fiber optic cable, ...") to item 60, 
host computer) . It would have been obvious to one in skilled in 
the art at the time of the invention to modify Adelman et al to 
couple mobile client (s) through a base station in order to make 
mobile units to be part of a cluster as taught in Harsch and 
Adelman (Harsch: see FIG. 1, mobile units 66, 66a, and 66b 
connected to ° host computer, 60; Adelman: FIG. 8F, showing 
joining of client into a cluster.). For claim 22: The system of 
claim 20 (see supra for claim 20 discussion) , wherein the 
presence server (cluster master, which is also cluster member, 
"... each of the cluster members is a computer system 
column 5, line 22; acting as master) determines measures of 
network load (determined by using the sequence number of 
keepalive and keepalive interval, Adelman: see FIG. 8C, item 
835; sequence number is the only variable to determine the 
network load.) by querying a controller that has access a 
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measure of network load (FIG. 1 in conjunction with FIG. 4,. FIG. 
1 Item 110 is the cluster one ether net connected to other 
network units. To get the sequence number master must have 
queried and obtained the packet from the Ethernet controller . ) . 

For claim 24: The system of claim 20 (see supra for claim 20 
discussion) , wherein the at least one mobile subscriber (after 
Harsch modification of alderman as discussed supra, mobile 
station is non-master client) upon receiving the selected 
keepalive period (Adelman: FIG. 8G, Item 890, "CLIENT GOT MASTER 
KEEPALIVE" ) , sends the next keepalive message at a time 
determined by the selected keepalive period Item 891, "UPDATE 
ADAPTIVE KEEPALIVE INTERVAL (CALCULATED BY MASTER)", updating 
the keepalive interval has the effect of sending the next 
keepalive message according to the updated keepalive interval.). 

6. Claims 5 and 11 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al in view of Rashid et al (US 
2004/0230661) . 

For Claim 5 and 11 Adelman et al teach all the claim limitations 
except for -polling (polling for claim 5) and pushing (for claim 
11) the network load information. The general concept of pushing 
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and polling information is well known in the art as shown in 
Figure 3, following item 302 to decide whether push or pull*. It 
would have been obvious to one in skilled in the art at the time 
of the invention to modify Adelman et al. to push or pull 
network information in order to implement authentication process 
as taught in Rashid et al (see Page 3, Para 0036-0042 for push 
based process and Para 0043-0045 for pull based process 

Claim 16 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al in view of rfc2543. For claim 16 
Adelman et al teaches all claim limitations except SIP message 
is being used as keepalive message. The general concept of using 
an SIP message as keepalive message is well known in the art as 
illustrated Internet draft session timer (page 3, second Para, 
"... this extension defines a keepalive mechanism for SIP 
sessions."). It would have been obvious to one skilled in the 
art at the time of the invention to modify Adelman et al to use 
SIP message as keepalive message in order to create sessions as 
taught in RFC 2543 (RFC 2543, page 1, Abstract, first line, "The 
Session Initiation Protocol (SIP) is an application-layer 
control (signaling) protocol for creating, modifying and 
terminating sessions with one or more participants", which . 
teaches SIP can be used to create sessions.). 8. 
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Claim 18 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman et al in view of Aharoni et al (US 
6014694) . 

For claim. 18, Adelman et al teaches all the claim limitations 
(as discussed supra) except changing keepalive period based on 
threshold change in network load. The general concept of 
changing timer value is well known in the art as illustrated in 
Aharoni et al (FIG. Item 116, "Bytes Online [network load] 
Recommended Bytes Online? [threshold]", yes no change, No, set 
TIMEOUT=1000 (setting a timeout period, i.e. setting keepalive 
time period to 1000, and waiting for acknowledgment from. item 
120) . It would have been obvious to one in skilled in the art at 
the time of invention to modify Adelman et al to change the 
keepalive period based on threshold change in network load in 
order to measure network bandwidth as taught by Aharoni et al 
(FIG. 11, starting step, "BANDWIDTH MEASUREMENT SCAN PHASE"). 

9. Claim 21 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman in view of Harsch and Rashid et al. 
For claim 21, Adelman and Harsch (as discussed supra in claim 
20) 1 teach all claim limitations, except polling the network load 
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information from the controller. The general concept of polling 
information is in well known in the art as illustrated in 
Rashid: Figure 3, following item 302 to decide whether poll or 
push. It would have been obvious to one skilled in the art at 
the time of the invention to modify Adelman et al and Harsch to 
poll the network load information in order to implement 
authentication process as taught in Rashid et al (Rashid: Page 
3, Para 0043- 0045 for poll based process) . 

10. Claim 23 is rejected under 35 U.S.C. 103(a) as being 
unpatentable over Adelman in view of Harsch and Aharoni et al 
(US 6014694) . For claim 23, Adelman and Harsch teach all the 
claim limitations except keeping track of the network bandwidth. 
The general concept of keeping track of network bandwidth is 
well known in the art as illustrated by Aharoni et al (Aharoni: 
FIG. .12, sender keeping (calculating) track of bandwidth as* 
shown in the top start item) . It would have been obvious to one 
in skilled in the art at the time of invention to modify Adelman 
et al. and Harsch to keep track bandwidth use in order to 
determine new time to send as taught in Aharoni et al. (see 7 
Aharoni: FIG. 12/2, item 160). 
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Conclusion 

1*. ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is 
reminded of the extension of time policy as set forth in 37 
CFR 1.136(a) . 

A shortened statutory period for reply to this final action 
is set to expire THREE MONTHS from the mailing date of this 
action. In the event a first reply is filed within TWO MONTHS 
of the mailing date of this final action and the advisory action 
is not mailed until after the end of the THREE-MONTH shortened 
statutory period, then the shortened statutory period will 
expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated 
from the mailing date of the advisory action. In no event,, 
however, will the statutory period for reply expire later than 
SIX MONTHS from the date of this final action. 

The prior made of record and not relied upon is considered 
pertinent to applicant's disclosure. 

Any inquiry concerning this communication or earlier 
communications from the examiner should be directed to Yasin 
Barqadle whose telephone number is 571-272-3947. The examiner 
can normally be reached on 9:00 AM to 5:30 PM. 
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If attempts to reach the examiner by telephone are 
unsuccessful, the examiner's supervisor, Glenn Burgess can be 
reached on 571-272-3949. The fax phone numbers for the 
organization where this application or proceeding is assigned 
are 703-872-9306 for regular communications and 703-746-7238 for 
After Final communications. 

Any inquiry of a general nature or relating to the status 
of this application or proceeding should be directed to the 
receptionist whose telephone number is 703-305-3900. 

Information regarding the status of an application may be 
obtained form the Patent Application Information Retrieval 
(PAIR) system. Status information for published applications may 
be obtained from either private PAIR or public PAIR system. 
Status information for unpublished applications is available 
through private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have 
questions on access to the Private PAIR system, contact the 
Electronic Business Center (EBC) at 866-217-9197 (toll-free) . 
YB 
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